1. Field of the Invention
The present invention relates generally to a security framework for protecting rights in computer software. More specifically, the invention relates to protecting computer software using fingerprinting, encryption, cryptographic triggers, license enforcement parameters, and build identification techniques.
2. Related Art
For the last twenty years, the protection of digital data and computer software from unauthorized use and copying has been, and continues to be, an unattained goal for the computer industry. This is a concern, because it is of course in the software developer's interests that each user pays for use of the developer's software.
Computer software is typically delivered in digital form through digital storage devices, such as computer disks or CDs, or through digital-communication channels, such as the Internet. Software, as with all digital content, has the property that it is easy and cheap to obtain multiple pristine digital copies from a single original, e.g., a purchased copy. This has traditionally baffled developers, who are unable to defend against pirates and unlawful competitors and must face losses and lower sales.
As a result of this technical drawback, the software business holds a natural, but atypical, property for a content provider business. Namely, the developer (or reseller) gives or sells the software to a client, while continuing to restrict the rights for using the software even after it is under the sole physical control of the client. For instance, a developer (or reseller) will typically retain copyright to a program so that the client cannot run an unbounded number of copies of this software without permission. A developer could also adjust the pricing for this software according to whether the client is allowed to use it only on his personal computer, or for a given number of times, or if he is just allowed to try it once.
It is in this sense, that the behavior of legitimate users of personal computers can turn adversarial to the interests of the developer or reseller. “Digital rights management” (DRM) is the name given to the subject covering solutions to these problems. It has been increasingly becoming a central requirement for the commerce of digital goods. Moreover, with the growth of software industry—and thus DRM—various types of license rights have emerged.
Generally speaking, a main objective of DRM, as applied to software, is to protect programs from software piracy. Here, software piracy is to be understood as the violation of the lawful rights given to the client by the developer. The main objective of software protection systems is to prevent software piracy by:
a) Obfuscation of the algorithm of a program, i.e., making it computationally infeasible for any user, be it rightful or unlawful, to understand the algorithm underlying the protected code;
b) The possibility of uniquely identifying each build (each generated copy of the software), using an embedded fingerprint system, thereby providing a link to the particular purchaser;
c) The infeasibility for attackers to remove the embedded fingerprint system in order to make the copy un-identifiable by the developer;
d) Implement binding parameters and license enforcement, which would entail a system of checks, implicit or explicit, that guarantee that the program is being used as established by the license policy; and
e) Ensure that it is computational infeasibility to have any unauthorized influence on the process of program execution that changes the logic of the program and/or protocol of the program's interaction with the user (this also would entail a system of checks, as mentioned above).
The use of fingerprinting to uniquely identify digital documents is discussed in “Tracing Traitors,” by D. Chor, A. Fiat, and M. Naor, Proceedings of Advances in Cryptology, CRYPTO 94, LNCS 839, Springer-Verlag, 1994.
Solutions for license enforcement are rarely capable of implementing fingerprinting functionalities. Reciprocally, fingerprinting systems can seldom be used for software protection. The present invention realizes both, and these software protection functionalities—especially the software non-malleability attained through software protection—will discourage pirates from removing fingerprints. At the same time, the fingerprinting will make software protection easier by providing the capability of tracing pirates.
Conventionally, software protection systems tend to make ad hoc combinations of hardware and software techniques. A typical software protection system is based on the techniques of making certain portions of the executable code unavailable to unlawful users. This is typically done by:
a) Enciphering certain portions of the programs code, and embedding the key needed for decryption (or the complete decryption algorithm) in a piece of protected memory, such as a smart card or hardware dongle (which is a sealed hardware device that stores a decryption key); or
b) having the code execute on a secure environment, such as a trusted computer.
Solution (a) suffers from the fact that, there is not such a thing as protected memory. Both smart cards and hardware dongles can be tampered with and the secret data retrieved. These attacks, which are referred to as “timing attacks”, and which have been done on implementations of Diffie-Heilman, Rivest-Shamir-Adleman (RSA), Digital Signal Standard (DSS) and other encryption systems, render the underlying solutions insecure. Solution (b) is likewise flawed, because users do not want to rely on connectivity to a network or remote machine for working. Moreover, unless huge portions of the software run on the secure machine, a pirate could “record” these portions and stop relying on the secure machine. But if huge portions of the software are missing (i.e., are located on the secure machine), then the software might as well run completely on the secure machine, which renders this protection scheme highly inefficient.
For example, U.S. Pat. No. 4,757,534 (Matyas) discusses a method for protecting software distributed by disk to clients. A unique encryption algorithm and key is used for each copy of the program. To run the program on a computer, a user must be in possession of a designated smart card in which there is stored the appropriate decryption key. This solution suffers from the problems of excessive cost, overly complex circuitry and user inconvenience. Moreover, no fingerprinting is used, and thus, the owner of a pirated copy cannot be detected.
With respect to convenience, users generally do not want to bother with the task of attaching and detaching a variety dongles to their computers as they switch from one software package to another. Dongles can consume unacceptably large areas of a desktop as more and more protected software packages are acquired from different vendors. With respect to computer performance, it is undesirable to have a software protection scheme that substantially slows the instruction execution speed of a CPU. There should be a way to protect the rights of legitimate software originators and distributors (copyright licensors and licensees) without inconveniencing end users. The cost of the protection means should be minimal to end users and degradation to CPU execution speed should also be minimal.
As a further example, in U.S. Pat. No. 5,056,140 (Kimbell), a software-only protection system is established for running licensed software on terminals within a network that are linked to a master computer. Software is executed on the terminal computers, but needs to pass through a challenge-and-response mechanism to start running. The security of this system relies on a cryptographically secure mechanism that defeats eavesdroppers. However, this system is defeatable in many ways, e.g., an attacker compromising the master computer would obtain total permissions to copy (and re-sell) the licensed software.
Connectivity between the terminals and the master computer is needed in this example. This is a drawback, since a secure implementation of this system (as a means for licensing software) should have the master computer located outside the internal (e.g., corporate) network, e.g., a computer owned by the software vendor and running in his headquarters. And this in turn can become awkward for users, for example, because they want to use it on their laptops, they use their telephone lines for connectivity, it consumes bandwidth, or because outsiders could monitor the communications with the master computer—though encrypted—to determine what software they use and when they use it. Otherwise, if the master computer were inside the home or corporate office of the licensee, any user of this internal network would be able to obtain full permissions to use and copy-for-use the protected application. Moreover, no fingerprinting is used in this solution.
In U.S. Pat. No. 5,123,045 (Ostrovsky et al.), a data processing system is used that provides protection of software from adversarial observers for a generic random-access machine (RAM) model of computation. No polynomial-time malicious pirate can learn any additional information about the compiled programs except their I/O behavior (even if the pirate experiments with the compiled programs and changes the contents of the memory as he pleases). This conclusion assumes that it is infeasible to open the physically protected chip without destroying the contents of its registers and that it is infeasible to invert a one-way function. The requirement for a physically protected chip is costly and burdensome, and it is unlikely that such a chip exists. Moreover, security mechanisms relying on this type of scheme tend to be insecure, as they are vulnerable to timing attacks. In addition, as mentioned above, users generally do not want to use additional hardware devices. Finally, no fingerprinting is provided by this solution.
In U.S. Pat. No. 5,375,206, the computer system where clients run licensed programs connects to a license server that monitors the usage of these programs, thereby permitting licensed users to run them and forcing users to follow the license policy. Each time a user attempts to use the software, the licensing software sends a network message to the license server requesting a “license token.” If a token is available, it is returned through the network to the computer running this software, and the software then performs its function for the user. When the user finishes using the software, the token is returned to the license server. When the server is out of licenses, the said software does not run.
This solution suffers from the fact that any unlawful user can impersonate the servers and thus run purloined software, or even break the license policy by running the software more than the permitted number of times. For example, a pirate could make a single, legal use of the software, keep the tokens used during this first execution, and when finished “rewind” the software to its initial state and re-use the tokens he first saved. This is often known as a “replay attack” in the security literature.
In U.S. Pat. No. 5,903,647, a computer-based, self-launching system associated with a software program or other digital information is provided for distributing the software program or other digital information to a potential purchaser. The self-launching system is attached to a software program or other digital information and includes the ability to launch itself when a user selects the software program or other digital information. Upon launching itself, the system unlocks the software program or other digital information in response to a purchase request. No fingerprinting is used in this system. Furthermore, once a user has purchased a protected program, he obtains an unprotected copy of this program that he may copy or redistribute at will. Also, different protected copies will be typically locked with the same key. This is a drawback, since once a purchaser posts his key on the internet, everyone that obtains a protected copy may unlock it with this key.
In U.S. Pat. No. 6,330,670 (England et al.), a digital rights management operating system protects rights-managed data, such as downloaded content, from access by untrusted programs while the data is loaded into memory or on a page file as a result of the execution of a trusted application that accesses the memory. To protect the rights-managed data resident in memory, the digital rights management operating system refuses to load an untrusted program into memory while the trusted application is executing or removes the data from memory before loading the untrusted program. If the untrusted program executes at the operating system level, such as a debugger, the digital rights management operating system renounces a trusted identity created for it by the computer processor when the computer was booted. To protect the rights-managed data on the page file, the digital rights management operating system prohibits raw access to the page file, or erases the data from the page file before allowing such access. Alternatively, the digital rights management operating system can encrypt the rights-managed data prior to writing it to the page file. The digital rights management operating system also limits the functions the user can perform on the rights-managed data and the trusted application, and can provide a trusted clock used in place of the standard computer clock.
This approach relates to an operating system that enforces DRM capabilities, and it requires the end-user to replace his operating system with the proprietary DRM operating system prior to accessing the protected application. Its effectiveness is based on the assumption that the operating system software running on the end-user workstation has not been tampered with, i.e., that the end-user workstation operating system is not a hostile environment for the protection mechanism.
In general, one of the weakest points in today's software is that protection or restrictions checks are made only once or at least a few times during programs execution. This lead crackers to patch the software very easily. Moreover, there are explicit warnings of such protection/restrictions in the applications which make it even easier for the cracker to look for specific code. The most common approach is to show a warning message and the close the application, so the attacker only has to bypass such function check and the application continues running.
Imposing code constrains allows the developer to tighten the whole application to work properly only if certain license conditions match. For example, if an application license establishes an expiration date, there typically are verification functions that check whether the present date and time are lower than the expiration date. If so, the application continues to run smoothly. When the expiration date has passed, the check fails, and the application is blocked from use (and the user receives an “expiration” note on the computer monitor display). From a cracker's standpoint, locating such functions and modifying their behavior would be enough to defeat a protection scheme relying only on these checks. By contrast, in the present invention, novel license enforcement methods are used that rely on the binding of the execution of the protected program to the license parameters.
The above-mentioned shortcomings, disadvantages and problems are addressed by the present invention. The present invention circumvents these problems by introducing a new technique, called cryptographic triggers, that enhances the power of the traditional and novel fingerprinting and policy enforcement functionalities. The coupling of the fingerprinting and policy enforcement functionalities together with the trigger capabilities produces, in fact, a cryptographically-secure protection method.